Wir hatten in der letzten Woche mit dem FT-Curver angefangen und hatten uns zuletzt mit dem

Thema der verschiedenen Replikationsarten beschäftigt, an der stelle ich noch mal einsteigen.

einsteigen. Also man entscheidet ganz generell einmal zwischen Stateless-Objekten. Also letztlich,

wobei Stateless, die Objekte mögen Zustand haben, aber er verändert sich eben nicht.

Und wir haben da lesenden Zugriff und das ist natürlich in Bezug auf die Replikation

die einfachste Form. Wir replizieren einmal und danach können wir halt einfach auf die

replizierten Objekte zugreifen. Und dann hatten wir letztes Mal angefangen mit Active Replication.

Das heißt also alle Replikate bearbeiten den Aufruf und im Fall eines Ausfalls habe

ich eine sehr geringe Verzögerung, weil ich natürlich jederzeit mit einem anderen Replikat

interagieren kann.

Warnpassive und Code Passive Replication schauen wir uns jetzt noch an.

Letztlich ein gradueller Übergang bei Warnpassive Replication.

Der aktuelle Zustand des primären Replikats wird ja periodisch an die anderen Replikate

übertragen.

Das ist dann auf die Weise, dass die Replication auf die aktuelle Zustand gehalten wird.

Zusätzlich werden Aufrufe protokolliert.

In dem Augenblick, wo ich einen Ausfall habe, besteht das Recovery letztendlich darin, dass

ich eigentlich nur noch die letzten Aufrufe seit dem letzten Zustandsupdate nachspielen

muss und auf die Weise den aktuellen Zustand bekomme.

Bei CodePersif habe ich Sicherungspunkte und ich muss dann bei einem Ausfall erstmal das

Replikat initialisieren mit dem Zustand des Sicherungspunkts und anschließend noch die

zusätzlichen seit dem Sicherungspunkt durchgeführten Aufrufe nachspielen.

Das dauert natürlich dann am längsten.

Bei Active Replication haben wir also im Normalbetrieb sieht es eben so aus, dass eben einfach

alle Aufrufe repliziert werden und im Fall von Ausfällen kann die Infrastruktur das relativ

transparent verschatten, weil eben mindestens ein Replikat auf die Anfrage noch antworten wird.

Das einzige, was wir natürlich noch ein Problem haben, ist in dem Augenblick, wo ein neues

Objekt in diese Objektgruppe der replizierten Objekte beitritt, muss ich natürlich einen

Zustandstransfer machen.

Das heißt da habe ich im Prinzip ähnliche Situationen wie bei der passiven Replikation,

dass ich letztendlich auch eine Zustandsicherung machen muss und einen Zustandstransfer machen muss.

Das hatten wir uns nochmal angeschaut.

Wir haben natürlich das Problem, in dem Augenblick werden wir so einen Aufruf machen, dass wir,

also wir machen hier einen Aufruf an die Replikate.

Jetzt antworten natürlich alle, wir müssen also Antworten unterdrücken.

Die Frage ist jetzt an der Stelle natürlich, wo machen wir das?

Lassen wir die Antworten alle zurückkommen und machen es beim Client.

Das ist natürlich in der Praxis vermutlich die beste Situation, weil der Client dann natürlich erkennt,

okay, das ist eine Antwort von einem Replikat, das ist auch eine Antwort vom Replikat.

Und man könnte dann sogar noch einen Schritt weiter gehen und die Antworten vergleichen.

Und wenn die Antworten nicht übereinstimmen, kann man natürlich auch darauf schließen,

dass da irgendwas nicht in Ordnung ist im System.

Also, eben die Frage, an welcher Stelle wird unterdrückt.

Das andere Problem war, wenn wir so ein repliziertes Objekt haben, das dann an einen dritten einen Aufruf macht,

dann haben wir natürlich eigentlich die Situation, dass jetzt da zwei Aufrufe landen.

Und auch da ist die Frage natürlich wieder, wo unterdrücken wir die Anfrage?

Unterdrücken wir bereits bei einem Replikat den Aufruf an den dritten,

oder können wir das hier im Org machen, dass hier zwei Aufrufe reinkommen?

Wenn man das mal ein bisschen weiterspielt, dann kommt da natürlich eventuell sehr schnell eine ziemlich komplexe Situation zustande.

Vor allem, wenn replizierte Objekte replizierte Objekte aufrufen.